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Things are certainly starting to happen in the 0S9 World! 

Firstly, we (that is, the Australian 0S9 Users Group) have finally been able to establish links with a number of 
reliable overseas sources of Public Domain Software. We have managed to establish links to a couple of guys in the 
Netherlands who are willing to provide us with as much material as we require from their collections, and also from 
the collection of the European 0S9 Users Group. Some 50 megabytes (yes megabytes) of PD software. We have also 
managed to get access to the Princeton University (USA) OS? Group Listserver on Internet, and can send and receive 
messages and files via that forum. Some very familiar (in the 0S9 Community) names are regular contributors to the 
discussions on that network. Such names as Kevin Darling, Mike Knudsen, Tim Koonce and Mark Griffith are common 
correspondents. And the material that they are currently discussing is always 'state of the art 1 0S9. 

Secondlyj we have seen the first CoCo4 'clone 7 released in the form of the 'TC9 TomCat' from Frank Hogg 
Laboratories Inc. The documentation that we have seen will make all 0S9 Users' mouths water (even the OSK types). 
I will try to give a synopsis of the documentation just to ujhet your appetite. Incidental ly, this description 
should not be taken as any kind of endorsement for the product. As usual, we are simply providing information 
about 0S9 and OS? related products. 

Let me quote from the advertising flier that I received in the mail: 

From 6809 to 68830 and beyond, with your present hardware, at your own pace... 

\^ere are some of the specifications for the TC9; 257. faster than a CoCo3, uses a PC compatible keyboard, has 2 
'real 7 serial ports, supports a serial mouse, has a parallel printer port, has provision for 512K onboard ram, OR 
can use a CoCc 3 512K ram upgrade, can be upgraded to 1 megabyte with the Disto 1 meg upgrade with no soldering, 
has 3 bit A to D and D to A converters, providing better sound and higher resolution joystick, supports an internal 
speaker, has a standard CoCc bus so that existing cartridges can be used, and is K-Bus compatible! ! 

K-Bus is FHL's standard OSK vehicle, and has been advertised in publications such as the US Rainbow Magazine. What 
is interesting, is that the TC9 does not have to be used with a K-Bus system, but can be used (with the addition of 
a case and power supply) as a stand alone CoCo3 clone. We aT9 presuming that the system is based on the Hitachi 
high-speed 6809 look alike chip. This means that everything simply runs faster that it would on a CqCqj, but with 
very few other changes. Interesting things start to happen when a K-Bus system is added. With the addition of a 
K-Bus system, interfacing to a 68000 (or even a 6S030) is simple, and the Tomcat then becomes a dual processing 
system. This means that when in OS? Level II mode, the 680X0 chip becomes a co-processor!! This should mean a 2 
to 3 fold improvement in performance. When the 680X0 is master, the TC? will act as a co-processor to OSK, 
Theoretically, this should make for a smooth transition between OS? and OSK. And of course, as soon as a K-Bus 
system is fitted to the TC9, all of the K-Bus peripherals become available for use with the system. 

The price? USt 299.95. But, you would have to add to that a case, keyboard and power supply just to get the thing 
going as a (fast) CoCo. I'm not sure that I will be racing to buy one at that sort of price!! 

The release of the second ? clone' machine, the Mttl is imminent, and there is rumour of even a third clone machine 
in the not too distant future. So, as I said, things are really starting to happen. 

I hope you enjoy this copy of the Newsletter. Cheers Gordon, 
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CREATING A BOOT DISK 
An addendum to "OS-9 From The Beginning' 



Last month's Newsletter contained an excellent Article 'OS-9 From The Beginning". During a discussion with Gordon 
it was agreed, as an addendum to OB-9 From The Beginning, that I should write an article on setting up a Boot Disk. 

Only what is contained on the original System Disks will be used to create a Boot Disk to maximise your system. We 
will also be setting up a disk from which you can easily create other Boot Disks when required. 

The MODPATCH utility will be used in modifying the System, so a simple explanation in its use will also be given. 
There will also be a chart detailing the Disk Drive Offset locations and the patches for those locations. The 
windows I will not cover here as I have already done so in the Dec 3? - Jan 98 Newsletter (page &). 

Having spent a couple of nights prior to writing this article attempting to operate e one drive system, I have 
decided that the first requirement of a one drive system is a second drive, A two drive system will be assumed. 

I am assuming you have booted your system with a backup copy of your original disk- Yen will have a system that is 
35 tracks single sided with a step rate of 3Bms, also a 32 column screen, at this point there is little we can do 
about the screen as GrfDrv is not in memory. What we can do is take a look at the changes that can be made to the 
drive descriptors. Study the chart below: You should find it self explanatory. 

19 22 
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This is where we learn how to use MODPATCH and in doing so put the finishing touches to your understanding of the 
above chart. 

MODPATCH allows you to link to a module, and change an Offset address in that module from one value to another, in 
this case it is going to be Dl, Why ?, because we need to format a 40trk double sided disk, and to do that we need 
a 40trk double sided descriptor in memory. We will leave D0 and DD remain as they are for now with the exception of 
the step rate. Most drives today can handle the 6ms stepping rate so I will be using that as an example. If your 
drives are different then choose the right value from the above chart, If you do not know try experimenting with 
just the step rate. The changes wont become permenant until! you use the COBBLER command. 

How do we do this? At the command line type MODPATCH <enter>. When MODPATCH loads, the cursor will be hard 
against the left side of the screen. Press <1> (that's a lower-case L) then the <space bar). Then type "Di" (the 
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module we are linking to.) Then press (enter). You will notice that everything you type echoesi don't worry, this 
is normal. To change anything, first locate from the chart, the offset that needs to be changed. As I said in the 
previous paragraph, I will change the step rate to 6ns. The offset for this, from the chart, is 14. The step rate 
of the original disk is 30ms, its value is 00. The 6ms value is 03. What we have to do now is to change the 
value at offset 14 from 00 to 03. What you have to remember is, that you change an offset FROM what it is, TO what 
you want it to be. 

It should go like this.... I won't show the echo. 

modpatch <enter> 

1 dl (enter) 

c 14 30 03 (enter) *The step rate from 30ms to 6ms 

c IS 23 23 <enter) *Tracks from 35 to 40 

c 19 01 02 tenter > *Sides from 1 to 2 

v <enter> *verify the changes. 

1 d3 (enter) *l_ink to D0 

c 14 00 03 <enter) *The step rate from 30ms to 6ms 

v <enter) *verify the changes 

1 dd <enter) *Link to DD 

c 14 00 03 <enter> *the step rate from 30ms to 6ms 

v <enter) *verify the changes 

<control-Break) *E>ats from modpatch back to OS? prompt. 

Try a few commands to test out your new found speed. Put a blank disk in /dl and type format /dl r "40 Track 
D/SIDE". When the formatting is finished, a "free /dl" command will reveal 1440 sectors, a little better than the 
630 sectors you originally had on your system disk. 

When everything is working satisfactorily, the number of tracks and sides for the D0 and DD descriptors can then 
also be changed. At this point the only changes that have been made, are in memory, and not on the system disk in 
/d0, or the newly formatted 40 track double sided disk in /dl. 

If you are satisfied with the modules you have in memory, make the changes to D0 and DD. You will also want your 
BOOT stepping at 6«s, so make this change also. 

1 boot (enter) 

c 017c 13 10 <enter) 

v (enter) 

< Control -Break) 

Now do a cobbler /dl (enter). This will put an 0B9Boot file on the disk in /dl which will include all the changes 
we have just made. To make this a system disk we need to copy all the files from the disk in /d0 to the new disk in 
/dl. There is a utility called DSAVE, in the CUDS directory that we can use for this. This is how it is done..... 

end /ti0 (enter) 

dsave /d0 /dl f shell (enter) 

Now sit back and watch a new system disk being created, or have a cup of coffee. 

This is the end for this month, next month I will be showing you how to create your own config procedure, that once 
completed will allow you to build your own boot disk, in a fraction of the time that config takes. 

If you have any queries please call or write Rob Unsworth 

(07) 202 4218 
20 Salisbury Rd 
Ipswich QLD 4305. 

ooqocqooooOOOOOOOOOOooogcooooo 
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The following article was sent to us by Peter Tutelaers of the Netherlands 0S9 Users Group, By kind permission of 
the authors, (although ye are not strictly an electronic medium) ye reproduce it here for your education. I guess 
that it becomes fairly technical in its treatment of the famous (or infamous, depending on your viewpoint) Boot 
Order Bug, and therefore will not be a great deal of use for ail of our members, .... Ed. 

C0C0-3 BOOT LIST ORDER BUG (BLOB) 

Facts, fixes and theories 

Kevin Darling & friends 

The BLOB 1 Some owners have it, some have never seen it. Ordering of modules in a boot list for os9gen seems to 
affect it. Adding new devices may cause it to show up. What causes it? It's past time to lay out both what has 
been conjectured and what is truly known so far. 

At first, the OS-9 kernel itself was blamed. We've been pretty sure now for a long time that it is NOT at fault. 
All the modules are position-independent, and have been gone over very closely by several of us, locking for 
anything that could cause a problem. We have found no software cause at all (with the exception of the disk driver 
- see below). Instead, hardware and timing discrepancies in the CoCc-3 and peripherals have been found almost 
always to be at fault. In fact, it's often possible to pinpoint the exact cause of a particular problem, with 
enough information. 

Enough preliminaries. \]ere are most of the confirmed and unconfirmed symptoms and possible reasons, including 
things that act like BLOBs... 

FLOPPY FORMATTING HALTS IN FIRST FEW TRACKS; READ/WRITES ARE OFF BY A BYTE: 

Ken Schunk, myself, an'd others long ago found that the halt method used by CC3Disfc (and some RSDOS drivers in 
programs) has a problem with some disk controllers (apparently mostly pre-1935 1773' s). The usual method is to 
wait for the FDC (floppy disk controller} to indicate it is ready to exchange a byte of data, and then have the 
Co Co go into the halt mode. What will happen is that the first byte transfer gets lost, and this is returned as a 
'Read Error 3 by the driver. 

For reasons as yet unknown, this "data lost' sequence sometimes 'seems 1 to be driver position dependent. I would 
guess that most boot failures are caused by this one, especially with older controllers (altho I've seen it happen 
on newer ones, too). The drivers can be fixed, and we should be able to post patches later. 

READS/WRITES 50 TO WRONG LSN: 

Actually, they go to the wrong TRACK, which is also always the wrong LSN. Usually caused by using disk drives that 
are set to turn on their motors only with drive select, instead of the required method of all motors on with the 
motor-on signal. All drivers assume that if one motor is on, ALL are on. Because of this assumption, and 
especially because the drive READY line isn't usually available on the CoCo setup, the FDC will send stepping 
commands to a drive that is still spinning up again when selected (it takes about 1/2 second to be actually 
"ready").... and those stepping pulses are totally ignored by drives not spun up. So while the FDC _thinks_ it's 
stepped the head to a new track, in fact either some or all of the step pulses h^e been lost, yorse, the 1773 FDC 
seems to ignore the imbedded track information on the disk itself (contrary to docs) and so as long as the sector 
number matches up, the data is read/written... to whatever track the head happens to be over 1 So make sure your 
drive motors all come on at the same time. 

SPEED AND BAD CHIPS 

Testing and experiences by several people has shown that the American semiconductor industry has gotten pretty bad 
oyer the last tew years as f^r as quality goes. Or perhaps retailers ^^ selling more reject chips that they buy 
on the grey market. In any case, some failures of craps used in add-on devices h^e been found to be brand 
dependent. For example, some of the LS245 data buffers inside CoCo-3's seem to fail to pass true data at times. 
Replacing this chip with a Japanese brand will usually cure this particular problem. Motorola chips seem to be zh^ 
worst bet. Symptom is that an instruction loop reading from the MPI sometimes sees bits set that it shouldn't. 
Solution is to replace the chip or slow down the loop, Speedwise, many people use hardware designed and built for 
IMhz operation from the CoCol/2 days. A common problem is with RS232 paks... they may need the 6551 replaced with 
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a higher speed version. 

INTERRUPTS 

Boot problems also sometimes appear when a device's interrupt line isn't correctly reset. I've had several 6551 
AC I As (used in RS232 paks, etc) that decided not to clear their interrupt line just by resetting the CoCo, This 
leaves an interrupt hanging and can mess up a machine trying to boot OS-9, It's also been found that some RS232 
paks were built with the E clock tied to the IRQ line... this can abort a boot also. Stuck interrupts are covered 
in the various 'IRQ HACK" files available on .most networks, as are files on the RS232 pak. 

MULTIPAK UPGRADE 

A non-upgraded ItPI definitely causes problems. At the least] it can cause wrong information to be read from the 
crucial GIME interrupt status port. The most common rumor we see on BBS's is that the MP I upgrade D isn't needed", 
because 'my machine runs fine without if. DO NOT LISTEN TO THESE PEOPLE. PLEASE EXPLAIN TO THEM THAT THEV ARE 
STUPID. While we can't swear that you WILL hurt your GIME if you don't upgrade, we can certainly say that it does 
make electronic sense to DO the upgrade (plus Tandy sold the upgrades at first cheaper than their cost, which alone 
would make one think there's a good reason for having it, eh?). The electronic reason for the upgrade is this: a 
READ from $FF80-9F will turn on BOTH \he GIME data bus AND the MPI data bus. (In addition, really old MPIs ghost 
their slot select at $FF7F and SFF9F, which causes problems.) It's never a good idea to have two devices trying to 
put data on a bus at the same time... one of them could get hurt (usually the GIME, in reported experiences). 
Especially under 0S-9j where the interrupt register at $FF92 is read at least 60 times a second, it makes sense to 
not have that data be corrupted by bogus MPI data coming on at the same time. So UPGRADE YOUR MULTIPAK NOW! 

E-CLOCK SYNCHRONIZATION: 

All accesses to peripherals need to use the 6839 E clock to validate the transfer of data (especially at 2Mhz!). A 
few early versions of third-party devices accidentally were made with registers that didn't do this. Ail have been 
fixed for a year now, as far as I know. The boot-order side of .this came about whenever a device register was 
accessed at an odd/even address, and then the next cpu instruction fetch was at the opposite even/odd address... 
which meant the A3 address line (or sometimes Al and maybe A2 also) would change after the E cycle ended and thus 
cause wrong device register addressing. This was shown on scopes as a small (around 10-ns) glitch. So the 
*position* of the driver I/O access instructions in memory was very important, and was a true common "boot order 3 
trouble causer (and may still be with older devices made in the pre-CoCo3 days). 

GIME S0-3 DECODING 

A variation of E-gating is that the SCS external select line is generated inside the CoCo-3 without being E-gated. 
This could possibly mean that while the GIME is decoding a different I/O selection, the S0-2 GIME lines decoded by 
the 74LS133 in the CoCo could easily wobble between outputs, possibly randomly enabling ROMs, PIAs, etc and placing 
bogus data on the bus. It also may be one cause of the video "sparklies". Again, using the E gating on devices 
should mostly solve this, altho it's also recommended that if you have problems you should gate the 133 with the E 
clock (Roger Krupski came up with the easiest method: inside the CoCo on the cartridge port, simply tie the E clock 
to the SLENE line. 

DOUBLE INTERRUPTS 

This is an oddball one. Sometimes people notice that their boot fails, or that their software clock runs at double 
speed while within a VDG screen. Quite by accident, I stumbled across evidence that certain address bit 
combinations in these situations causes double the vertical interrupts to be generated. No solution except to boot 
to a real window always, and if you have this clock problem to change the order in which you start up a game, so 
that it's video address can be moved somewhere "safe", This also seems to be SIME dependents Non-upgraded MPIs 
can cause this also, I think. 

OTHER HARDWARE PROBLEMS 

Zati connections. Bad connections. Bad connections. Clean all your contacts regularly. The cartridge port, the 
MPI and slot pins* all rompak devices, disk drive cables, and even yank your GIME anu swab it with alcohol if need 

Page 6 June 19-i/i 



AUSTRALIAN 0S9 NEWSLETTER 

be, altho sometimes just pushing/topping en it cures many oddball troubles. Make sure your drives don't have 
something covering the ante-protect detect LEDs. In general, just keep everything clean 1 It's also about now 
that many disk drives in use for years, are wearing out or becoming misaligned, Heads become a lot weaker, and 
data becomes flaky. We've also seen cases where a new cordless phone i or appliance on the same circuit breaker? 
can screw up floppy or hard disk transfers. Even satellite dish downfeeds running by the computer, If you start 
to have problems, ask yourself "did anything change here lately? 3 

OTHER SOFTWARE PROBLEMS 

More and more often, we find that many supposed boot list problems often have an unrelated simple explanation... 
such as making a new boot and forgetting that you patched some modules or used old ones; the common "oops forgot to 
put Grfdrv and Shell in the CUDS directory" gotcha; leaving out a module. Very often it can be caused by not 
having the latest drivers for a device. It's important to keep updated with the newest software made available. 
Also, sometimes a module (especially os?pl) will, get hit by an errant program, and then you os?gen a new disk... 
which gets perpetuated with the bad os9pl from then on through new os9gens. We also find that people often 
reverify a bad module quite by accident using disk editors on their bootfilsi thus hiding future trouble. Keep a 
log of all changes you make, and CRCs! 

HISC THEORIES 

Most other problems fall into the mystery section (meaning we don't have a firm handle on the cause yet). I have 
two pet ideas that may or may not make sense, but which are bolstered in part by experiences by myself and others. 
One is that since interrupts cause the internal BASIC ROM to turn on (to get the interrupt vectors), the ROM stays 
on a bit too long and corrupts the data bus at times. Probably a dumb theory <grin>. The other is that the dead 
cycles within many instructions have an effect. During the dead cycle the address bus contains tFFFF (which turns 
on the ROM!) and again, ' perhaps this data sticks around, .or the address lines change too fast enough once in a 
while from true address to FFFF. This ties in with partial evidence that some 6S0?s at 2Mhi will start changing 
their address lines immediately after the end of an E cycle, perhaps even before E-gated devices finish up. We do 
know that oddball reads/writes occur at times to strange addresses, and this might explain them. . A third theory 
gaining some acceptance (but we just don't know how the GIME works internally) is that the 5IME, like the SAM chip, 
powers up using either the up or down side of the main oscillator clock (remember hitting reset on SAM machines to 
get the right red/blue fake color phase? like that). Perhaps one side is better than the other. Certainly 
powering down sometimes cures a boot or other problem. So who knows? We also know that changing cpu brands, and 
sometimes switching GIMEs, will often cure timing problems and the sparklies, Not always, though. 

CONCLUSIONS 

We're still gathering data, and occasionally do run across something unexplained. For the most part though, BLOBs 
have become fairly rare. This may be because people have more L-II experience, or newer hardware, or a 
combination. OS-9 itself is not at fault, and note that even RSDOS applications can and do suffer from the same 
symptoms. The basic answer is that we moved up to a faster machine, while still using older peripheral equipment. 
The order of the boot list CAN affect the symptoms (as we've seen), but this is simply software showing up hardware 
bugs, and is NOT the fault of OS-9 itself. So the final word is this: our best evidence is that there really 
_isn 3 t_ a boot list order bug. Look to your hardware instead. - kevin darling 

The above information has been gleaned over the past two years from personal experience, many phone calls and 
network messages, and the work of Bruce Isted, Tony DiStefano, Chris Burke, Roger Krupski, DP Johnson, Dave Wiens, 
Ken Schunkt and many others, 

This file may be reposted on BBS's and other electronic networks, but may not be used in commercial publications 
without the author's permission. 

PS 5 if you have anything to add, please send information to me at i 

76703,4227 - CompuServe 

0S9UGPRES - del phi 

uunet ! 7&7S3. 4227Scompuserve. com 

(Or for 0: 0S9 UG, send to Gordon Eentzen. and we «- "1 1 1 get the message to him ... Ed) 
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OS-9 FROW THE BEGINNING - Part 2 



This month we continue this series which is aimed at new users of OS-? and is written around the "standard 9 modules 
of the Hicroware OS-? operating system distributed by Tandy for the Color Computer 3, 

I trust that the comments in last month's article and the "Getting Started 9 section of the OS-? manual have 
resulted in a bootable disk which will fully utilize the capacity of the system hardware. We can now move on to 
some simple analysis of the operating system and system modules. At the OS?: prompt, try entering B mdir a . 

H mdir a will produce a directory of all modules currently in memory* and will be similar to the listing below 
depending on the selections made during the "config" program, and current programmes. The display format will 
depend on the screen type, 3 columns for 32 or 43 column screens or 5 columns for an 80 column window. 

Module Directory at 28:26:35 
REL Boot 0S9pl 



0S9p2 


Init 


IONan 


CC3I0 


REF 


DD 


CC3Bisk 


D0 


Dl 


SCF 


Windlnt 


Term 


W 


wi 


W2 


W3 


y4 


m 


% 


W7 


PRINTER 


P 


Clock 


CC36o 


Pipe 


Piper 


PipeMan 


T2 


ACIAPAK 


Printerr 


GrfDrv 


Shell 


Copy 


Date 


Delni: 


Del 


Dir 


Display 


EchD 


Ini: 


Link 


List 


Load 


MDir 


Merge 


tifree 


Procs 


Rename 


Setime 


Tmode 





B mdir e* will provide an extended directory with information about each module in memory. Here is a listing of 
only some of the modules. 

Module Directory at 23:57:35 

Blk Of st Size Ty Rv At Uc Name 



3F D06 12A CI 1 r 00 REL 

3F E33 1D3 CI 2 r 01 Boot 

3F 1003 ED? C0 8 r 30 0S?pl 

31 1300 CAE CB 2 r 01 0S9p2 

31 1FAE 2E C0 1 r 01 Init 

31 1FDC ?F3 CI 1 r 01 IOHan 

31 29CF C36 El 1 r 33 CC3I0 

If the listing scrolls off the screen, <CTRL> W will pause the screen (hold down the CTRL key while pressing the W 
key), hit any key (except BREAK) to resume the listing, Or better yet, enter the command 'tmode pause" prior to 
the B mdir E command. This will cause the list to pause as scon as the screen fills. Hit any key to continue. The 
command to turn OFF this screen pause is 9 tmode -pause", Also try other system commands (modules) from the OS-? 
Commands Reference section of the manual, like HFree eh. 

MULTI-TASKING 

The easiest way to see a sample of multi-tasking is to start another "immortal" shell m another uindouj. The 
default setup of window descriptors can be used to begin with, refer to the manual section WINDOWS, page 1.3, for 
the default parameters of each window device descript^ --.3 147 is an S3 column? text type, of 24 lines (a full 
screen ) . 
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The command at the prompt to start another shell would look like this when typed, OS?: shell i=/w7& <£uier> 
This will startup an immortal shell m usindow W7 using i'U-p default values of window type, colours and sire, The 
ampersand (&) will tell OS? to run this shell as a concurrent process, Pressing the CLEAR key will switch between 
the TERM screen and the Window W7. 6o to W7 and enter any 0S9 command, e.g. "mdir e\ 039 is now mu.lt i -tasking. 
Use the same cDiTiniand a shell i=/w?& a (where w? is the number of any valid window device descriptor in memory) to 
startup another Shell i and enter some commands in each window (CLEAR key to flip between lit in dews). Try the command 
"procs" in one of the windows, and OS? will report the current processes. 

To terminate a SHELL that has been started in a window the command is "ex\ This will also close the window. 

A window does not need to have a shell running for it to exist. Output of most commands can be re-directed to any 
valid DEVICE such as disk drive (dS), printer (P), or window (w3). 

The command "mdir e B redirected to window 6 would be "mdir e >/wd fi . The listing would be sent to U&. Note however , 
that in this case the window Hh must not have a shell running. OS"? will redirect the output of the command "mdir" 
to window W6 by opening the window, and display the listing. The window will close again on the completion of the 
output unless memory has been reserved for that window. The command "iniz /w6 a will reserve memory and maintain 
the displayed listing on completion of 'mdir 3 

The opposite of a iniz 3 is 'deiniz 3 . The command "demiz wt fl will return the reserved memory to OS? and close the 
window. 

The OS? manual, "Windows 9 section? contains ail the information on the use of "wcreate 3 or "display' to modify the 
default setup valid window descriptors. The window descriptors can also be configured to a desired display so that 
repeated modification is not necessary, refer to the article Windows Explained 3 by Rob Unswcrth in our December 
1989 newsletter. 

Until next month, have fun with the OS? level 2 windows and the multi-tasking which we all love. 

Gordon Bentzen. 
oogoooooooOOOOOOOOOOdooooooogo 
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NATIONAL 0S9 USER GROUP APPLICATION / RENEWAL FORM 



C 3 SUBSCRIPTION feEWAL C 3 NEW SUBSCRIPTION 



Surname : hirst Name : Title (Mr, j etc): 



Street : 



Suburb : State : Postcode 



Home Phone : Business Phone 



Do you run 0S9 Level 1 [__3 and/or OS? Level 2 [„3 (please tick) 



Type of Computer for 0S9 



Diskette Size (inches): __ Number of Tracks: Sides: Number of Drive? 



Special Interests : 



Can you contribute articles to this Newsletter ? 



Date : / / Signature : 

Amount Enclosed: $ i $18-03 uii 1 1 cover you for 12 months) 

(cheques payable to National 0S9 User Group) 

NOTE: All current subscriptions E>:pire AUGUST 31st, 1993 

- Renewals Commence SEPTEMBER 1990 

Please Return Completed Form to *~ 

NATIONAL 0S9 USER GROUP 
C/d Gordon BENT7EN 
3 ODIN STREET, 
SUNNYEANK QLD 4129 




VIDEO DIGITIZER 




Capture images from a video camera or 
home VCR (with a good pause-still). 

Transfer images to CoCoMaxS , ColorMaxJ 
or MV-Canvas for further editing. 

features include: 

* No multi-pak red. Plugs into joy port: 

* Supports full CoCo3 Hi-Res display. 

* Slide show program included. 

* Easy to use Pop-up-Menu system. 

* Made and designed in Australia. 



WRITE TO US FOR A FREE DEMO/INFO DISK. 
OTHER PRODUCTS: 

* MV-Canvas Ver . 2 (OS-9 Paint program. Rqrs OS-9 & Multiview) ... AVAILABLE SOON 

* RAS*MAX (Print 4096 colour RASCAN images on CGP-220 & STAR NX-1000 ) . . . $20 . 00 

* CGP*MAX (Print CM3 , GIF, MGE or HSCREEN2 pictures on CGP-220) $15.00 

* STAR'MAX (As above but for STAR NX-1000) AVAILABLE SOON 

* Z'89 (New CoCo3 version of Zaxxon. ) ONLY 5 COPIES LEFT! . .$30.00 

* PYRAMIX (Like arcade Q-BERT.) ONLY 4 COPIES LEFT ! . . $20 . 00 

* DONUT DILEMMA (10 level platforms game) SPECIAL. . . $6 . 00 

* RUPERT RYTHYM (16 level strategy/arcade platform game) SPECIAL ... $6 . 00 

* SPACE INTRUDERS (an old classic re-vitalised) SPECIAL. . .$6.00 



NOTE - ALL PRODUCTS ARE ONLY FOR THE CCC02 WITH DISK DRIVE EXCEPT DONUT DILEMMA 
(CoCo 1/2/3, disk or tape) AND RUPERT RYTHYM (CoCo 3, disk or tape). 



Cheque or postal money order only 
NICKOLAS MARENTES P.O. EOX 6551 UPPER MT.GRAVATT OLD 
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